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1  Scope 

1. 1  Overview 

UGV  Interoperability  Profile  (IOP)  version  0  (VO)  has  been  defined  by  the  RS  JPO  to 
serve  as  a  commonality  baseline  that  can  be  successively  built  upon  by  subsequent 
versions  of  the  IOP.  This  commonality  baseline  is  largely  interpreted  as  “common”  with 
the  robotic  capabilities  currently  employed  in  fielded  operations  today  as  well  as  those 
capabilities  planned  to  be  acquired  via  robotic  program  initiatives  over  the  next  few 
years.  This  document  provides  general  guidance  and  clarification  with  respect  to  the 
set  of  interoperability  capabilities  to  be  covered  within  the  VO  UGV  IOP. 

In  general,  this  IOP  Capability  Plan  will  be  a  “living”  document  that  will  address  specific 
requirements  and  capabilities  applicable  to  planned  and  emerging  robotic  systems  and 
will;  in  coordination  with  the  RS  JPO,  User  Community,  and  UGV  IOP  Interoperability 
IPT  align  those  capabilities  to  future  IOP  Versions  that  will  in  turn  be  aligned  with  robotic 
program  acquisition  initiatives. 

1.2  Applicability 

This  document  was  developed  as  a  means  to  provide  details  associated  with  VO 
capabilities  by  providing  capability  intent  along  with  associated  limitations  and 
constraints  as  applicable  to  the  VO  development  effort.  This  document  serves  to 
provide  guidance  to  the  WIPT  organizations  participating  in  the  VO  development  in 
identifying  and  defining  systems  and  controller  inter/intra-interoperability.  This 
document  does  not  define  how  things  are  to  be  done  (implementation  of  requirements 
to  interoperability  standards  or  messages).  In  addition,  while  this  document  will  retain  a 
level  of  traceability  to  the  VO  lOPs,  that  traceability  will  not  necessarily  be  a  one  to  one 
correlation  between  a  defined  capability  and  the  manner  in  which  it  may  be  specified. 

2  Capabilities  Definition  Process 

The  simple  intent  of  the  capabilities  definition  process  is  to  identify,  specify,  and  define 
key  robotic  capabilities  and  assign  them  in  an  aligned  sequential  fashion  to  IOP  version 
releases  with  respect  to  a  determined  acquisition  need  date.  Initially  this  is  very  difficult 
to  do  given  the  fact  that  VO  capabilities  span  a  set  of  capabilities  that  have  already  been 
fielded  as  well  as  a  set  of  capabilities  that  will  be  fielded  in  the  near  future.  At  some 
point  in  time,  this  paradigm  will  shift  and  the  capabilities  identified  in  this  plan  will  be 
able  to  be  defined  in  advance  of  a  projected  acquisition  initiatives  allowing  for  the  ability 
to  define  interoperability  mechanisms  that  can  then  be  employed  as  part  of  the 
acquisition  cycle. 

With  respect  to  VO,  capabilities  were  identified  by  two  different  methods  and  then  vetted 
within  the  RS  JPO  and  the  User  community.  The  first  method  involved  an  analysis  of 
currently  fielded  systems  and  the  identification  of  common  capabilities  in  accordance 
with  the  IOP  Capabilities  taxonomy  defined  within  the  Overarching  IOP.  Current 
systems  that  were  analyzed  included  the  PackBot,  Talon,  and  MARCbot  platforms 
(some  in  varying  configurations).  The  second  method  included  analyzing  requirements 
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specifications  and  identifying  capabilities  for  systems  either  in  procurement  or  in 
development  within  the  User  community.  Systems  that  fell  into  this  category  included 
the  SUGV  and  the  SMET. 

In  successive  versions,  this  capabilities  plan  will  be  more  directly  tied  to  artifacts 
developed  within  the  program  acquisition  and  User  community,  such  as  the  Unmanned 
Systems  Initial  Capabilities  Document,  the  Robotics  Roadmap  and  the  UGV  Campaign 
Plan.  As  many  of  these  artifacts  were  being  developed  at  the  same  time  as  this  version 
of  the  campaign  plan,  it  was  not  practicable  to  achieve  the  same  level  of  synergy  as  that 
planned  for  future  versions. 

The  fact  that  VO  draws  its  capabilities  from  an  existing  base,  comprised  of  platforms 
developed  among  a  set  of  disparate  vendors  as  well  as  a  set  of  capabilities  defined  and 
addressed  within  the  JAUS  community,  the  complexity  and  intent  is  less  vague  than 
capabilities  that  were  purely  developmental  in  nature.  This  fact  should  prove  helpful 
with  respect  to  interpretation  and  in  general,  simplify  the  effort  associated  with 
interpreting  and  defining  the  VO  capabilities.  As  the  process  evolves  and  moves  into 
new  capabilities  that  are  not  part  of  today’s  robotic  fleet  the  gaps  will  increase,  requiring 
more  reliance  and  guidance. 

3  Capabilities 

The  capabilities  defined  below  are  presented  in  accordance  with  the  IOP  Composability 
taxonomy  defined  within  the  Overarching  IOP.  It  should  be  noted  that  even  though 
these  capabilities  are  specified  as  “common”  by  nature  of  the  VO  definition,  it  is 
understood  that  not  all  capabilities  will  be  available  within  every  robotic  system  and  in 
some  cases,  there  may  be  some  variation  in  how  the  capability  is  defined/provided. 

The  goal  of  the  IOP  is  to  define  an  interoperable  manner  to  address  these  capabilities 
across  robotic  systems,  i.e.  -  to  address  the  manner  in  which  systems  may  choose  to 
implement  or  not  implement  various  capabilities  (e.g.,  through  interoperability  attributes 
and/or  metadata  definition).  In  addition,  the  goal  is  to  also  providing  ways  for  external 
systems;  e.g.,  controllers,  to  know  what  capabilities  are  available  from/configured  for  a 
particular  platform  in  compliance  with  the  IOP.  This  is  an  overriding  requirement  to  be 
addressed  consistently  throughout  the  IOP,  the  manner  of  which  is  not  explicitly  defined 
as  a  capability  within  this  plan. 

In  addition,  the  definitions  below  serve  as  guidelines  and  are  inclusive  or  exact.  The 
definitions  are  specified  to  relay  intent  with  the  understanding  that  WIPTs  may  need  to 
extend  or  modify  the  definitions.  The  limitations  and  constraints  provide  somewhat 
loose  boundaries,  but  in  general  are  specified  to  limit  unnecessary  effort  to  over  specify 
capabilities  with  respect  to  their  interoperability  implementation. 

3. 1  Platform/Vehicle 

The  platform/vehicle  capabilities  are  those  capabilities  inherent  to  the  robotic  platform 
independent  of  mission  equipment  payloads.  In  general,  these  capabilities  define 
interoperability  requirements  relating  to  the  state  of  the  robotic  system  and  provide  for 
control/movement  of  the  robotic  system.  The  platform/vehicle  capabilities  are  subset 
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into  basic  and  advanced  capabilities  where  basic  refers  to  capabilities  applicable  to 
most  platforms  and  advanced  refers  to  capabilities  that  provide  enhanced  reporting  and 
control  common  or  specific  to  more  advanced  robotic  systems.  For  version  zero  (VO), 
only  basic  capabilities  are  addressed.  The  manner  in  which  advanced  capabilities  are 
further  subset  and  defined  will  be  addressed  in  future  versions  of  this  document. 

3.1.1  Electrical,  Mechanical,  and  Power 

Description:  These  capabilities  provide  for  the  definition  of  standards  to  promote 
interoperability  of  platform/vehicle  subsystems  and  payloads. 

Limitations  and  Constraints:  The  intent  of  this  capability  with  respect  to  version  0  is  to 
accommodate  currently  fielded  systems  at  a  minimum  and  to  start  to  define 
interoperability  attributes/mechanisms  to  profile  requirements  and  standards  in  these 
areas  to  accommodate  the  scalability  of  robotic  platforms.  In  general,  the  platforms  for 
consideration  fall  into  the  following  classes:  Soldier  Transportable,  Vehicle 
Transportable,  and  Self  Transportable.  Physical  standards  for  micro  and  nano  robotic 
platforms  are  not  a  high  priority  (e.g.,  nanobots  and  throw  bots). 

Other  Guidance:  To  the  degree  possible,  standardization  of  power,  connectors,  and 
mechanical  mounting  should  be  considered,  with  power  and  connectors  being  the 
highest  priority. 

3.1.2  Basic  platform 

Basic  platform  defines  capabilities  associated  with  the  physical  infrastructure  that 
contains  and  supports  various  robotic  system  subsystems.  The  capability  requirements 
in  the  basic  platform  are  the  most  basic  requirements  for  a  robotic  system  to  function. 

3.1. 2.1  Battery  Status 

Description:  Provides  the  status  of  the  battery(ies)  utilized  to  power  the  robotic 
platform  and  the  OCU.  The  intent  is  to  provide  a  current  charge  level  of  the  battery. 

Limitations  and  Constraints:  The  intent  is  to  provide  just  the  charge  level  of  the 
battery,  allowing  the  user  to  make  informed  decisions  about  mission  capability.  In 
subsequent  versions,  additional  information  may  be  added  (e.g.,  battery  chemistry, 
loads,  temperature,  critical  levels).  The  WIPTs  may  add  additional  information  as 
deemed  important  for  basic  functionality,  but  advanced  functions  should  not  be  pursued 
at  this  time. 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended.  Physical 
connections  will  need  to  be  considered,  such  as  U.S.  Army  DWG#  SC-C-1 79495  (for 
the  BB2590).  Power  standards  may  need  to  be  created  for  the  various  vehicle  classes. 
Low  power  warnings  may  also  need  to  be  discussed.  The  WIPTS  will  need  to  determine 
these  power  standers  and  limits. 
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3.1. 2.2  Usage 

Description:  Provides  the  ability  to  record  or  track  the  usage  associated  with  the 
robotic  platform.  The  usage  will  likely  be  stated  as  a  distance  traveled  and  hours  of 
operation  of  the  system  (one  set  for  the  platform,  and  one  set  for  the  OCU).  Much  like 
an  odometer,  this  should  not  be  reset,  however  a  single  use  “trip  meter”  may  be 
included  if  it  is  deemed  necessary.  This  should  not  be  confused  with  “usage”  as  defined 
with  respect  to  JAUS. 

Limitations  and  Constraints:  Basic  functionality  in  IOP  VO  should  allow  for  usage 
times  or  distances  to  be  recorded  /  reported.  There  is  no  expectation  that  the  basic  data 
will  be  used  for  advanced  features,  such  as  prognostics  at  this  time. 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended. 

3. 1.2. 3  Engine  Data 

Description:  Provides  information  required  for  the  user  to  operate  the  robotic  platform 
with  a  basic  engine  as  the  energy  source.  This  could  include  information  such  as  fuel 
levels,  engine  RPM,  Oil  Pressure,  and  Oil  Temperature  as  well  as  other  parameters 
deemed  necessary  by  the  WIPT  members. 

Limitations  and  Constraints:  The  intent  is  to  provide  basic  information  for  a  basic 
engine.  As  new  energy  sources  and  advanced  engines  (e.g.,  compressed  natural  gas, 
hydrogen,  sterling  engine)  are  introduced  and  requested,  they  can  be  added  to  later 
versions  of  the  IOP. 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended.  Messages  required 
for  driving  vehicles  will  be  captured  under  the  Basic  Mobility  Capability. 

3. 1.2.4  Platform  Mode 

Description:  Provides  a  definition  of  the  states  associated  with  the  robotic  platform  and 
may  be  utilized  as  a  means  to  specify  available  functionality  associated  with  the 
platform  itself  or  with  integrated  mission  packages/payloads. 

Platform  mode  describes  the  current  operational  state  of  the  robotic  system.  This  may 
include  startup,  shutdown,  standby,  ready,  in  use/busy,  and  reset.  It  may  also  include 
modes  as  determined  by  the  WIPT  membership.  The  platform  mode  is  different  than  the 
drive  mode,  in  that  all  drive  modes  could  go  into  a  startup  or  standby  mode,  or  be  reset. 

Limitations  and  Constraints:  The  most  basic  set  of  platform  modes  should  map  to 
most/all  robotic  systems  even  if  they  do  not  specifically  report  a  platform  status  (e.g., 
startup,  operational,  shutdown).  Additional  modes  such  as  maintenance,  standby, 
timed  shutdown,  anti-tamper,  render  useless  are  envisioned  for  future  robotic  systems, 
but  are  not  at  this  time  considered  part  of  the  basic  capability. 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended.  WIPTs  may  want  to 
consider,  but  not  necessarily  define,  future  state/mode  requirements  when  deriving  this 
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capability  as  a  means  of  defining  a  platform  mode  element  that  can  be  scaled  to  meet 
future  capability  requirements. 

3.1. 2.5  Position/Attitude 

Description:  Provides  a  standard  mechanism  to  report  the  position/attitude  of  the 
robotic  platform.  For  the  basic  platform,  this  is  envisioned  to  be  a  geo-referenced 
location  on  the  earth;  a  heading  (referenced  from  the  front  center  of  the  vehicle);  and  an 
indication  of  the  pitch  and  roll.  It  is  recommended  that  the  system  report  based  on  a 
local  reference  frame,  as  well  as  a  global  reference  frame,  such  as  the  WGS84 
standard.  The  WIPTs  may  determine  other  standards  for  position  and  attitude. 

Limitations  and  Constraints:  The  location  and  attitude  (heading,  pitch,  roll,  etc...) 
include  only  a  simple  data  point.  Later  versions  can  include  more  advanced  information 
as  required.  This  capability  should  be  defined  to  allow  for  systems  to  partially  conform 
in  accordance  with  their  ability  (e.g.,  report  location  and  heading  only  in  the  absence  of 
an  internal  navigation  package). 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended.  Additional 
standards  will  need  to  be  identified  to  accurately  describe  the  data  point. 

3.1. 2.6  Subsystem  Configuration 

Description:  Provides  the  ability  to  identify  and  report  the  presence  and  type  of 
payloads  available  to  the  robotic  platform.  In  addition,  this  capability  provides  a  high 
level  interface  to  enable/disable  integrated  subsystems.  This  will  be  related  to  discovery 
services. 

Limitations  and  Constraints:  This  is  a  high  level  capability  that  provides  information  to 
the  operator  regarding  the  system/subsystem  level  configuration  of  the  robotic  platforms 
and  its  integrated  payloads.  Examples  include  statements  identifying  the  ability  to  move, 
use  cameras,  or  the  type  of  payloads.  The  level  to  which  the  robotic  system  reports  this 
information  will  be  largely  a  function  of  the  program/system  design,  but  conceptually  this 
capability  will  scale  to  support  more  advanced  capabilities  associated  with  future 
revisions  (e.g.,  calibration,  BIT/FIT,  power  management). 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended.  Physical 
connections  will  be  captured  under  the  payload  and  overarching  sections. 

3. 1.2.7  Subsystem  Health 

Description:  Provides  a  high  level  health  status  (Ok,  Failed,  Degraded)  associated  with 
the  platform  subsystems.  This  capability  is  closely  associated  with  the  Subsystem 
Configuration  with  respect  to  the  subsystem  reporting  and  tree  structure. 

Limitations  and  Constraints:  The  health  monitoring  only  provides  basic  information 
and  is  not  intended  to  provide  in  depth  diagnosis/fault  reporting.  Advanced  messages 
describing  the  exact  failure,  nature  of  the  failure  or  prognostics  may  be  added  in  later 
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versions,  and  could  be  included  in  a  system’s  specification  outside  of  the  interoperability 
profile. 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended. 

3. 1.2.8  Pose/ Articulation 

Description:  Specifies  a  set  of  pre-programmed  poses  that  a  robotic  platform  may 
utilize.  Not  all  systems  will  utilize  all  poses,  but  a  base  set  of  poses  can  be  developed 
for  use  with  an  interoperable  controller.  Examples  could  include  “stow”,  “deploy”,  and 
“drive”. 

Limitations  and  Constraints:  Some  systems  may  have  many  poses,  while  others  may 
have  few  or  no  poses.  For  this  capability  only  basic  poses  should  be  considered.  In 
subsequent  versions,  the  ability  of  the  system  to  send  possible  pose  descriptions  to  the 
operator  may  be  considered.  This  capability  may  be  limited  by  the  payloads  placed  on 
the  system,  and  may  be  limited  in  functionality  for  IOP  VO.  The  WIPT  and  user 
community  will  decide  on  these  poses. 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended. 

3.1 .2.9  E-Stop,  or  Emergency  Stop 

Description:  The  robotic  system  should  be  able  to  receive  an  emergency  stop 
message  which  places  the  robot  into  a  safe  state  (this  state  will  likely  need  to  be 
considered  in  the  definition  of  the  platform  mode). 

Limitations  and  Constraints:  The  E-stop  should  be  able  to  place  the  robotic  system 
into  a  safe  state;  however,  it  is  understood  that  the  term  “safe”  may  be  interpreted 
differently  in  accordance  with  the  robotic  system  design  (for  example,  this  could  be 
interpreted  as  a  complete  shutdown  for  some  systems,  while  for  other  systems  a  less 
harsh  interpretation  may  be  considered).  In  addition,  certain  systems  may  have 
overriding  “stop”  or  “E-stop”  actions  defined  as  part  of  their  system  design  and/or 
performance  spec.  For  this  capability,  the  WIPTs  will  attempt  to  best  define  an  E-Stop 
capability  and  resultant  action  that  can  be  best  adapted  given  these  ambiguities. 
Subsequent  versions  may  attempt  to  provide  more  specific  actions  or  progressive 
capabilities  associated  with  this  requirement. 

Other  Guidance:  JAUS  messages  may  need  to  be  recommended. 

3.1.2.10  Heartbeat  (Liveness) 

Description:  Specifies  the  provision  of  a  simple  heartbeat  mechanism  to  detect  the 
introduction,  removal  or  failure  of  communications.  This  is  often  used  to  provide 
awareness  and  reaction  to  a  loss  or  intermittency  of  communications. 

Limitations  and  Constraints:  At  a  minimum,  a  high  level  duplex  heartbeat  between 
the  robotic  platform  and  its  controller(s)  is  deemed  to  be  sufficient  to  support  the  basic 
capability. 
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Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.1.3  Mobility 

3. 1.3.1  Drive  Mode 

Description:  Specifies  a  set  of  modes  used  to  position  the  platform  utilizing  the 
integrated  mobility  system  such  that  the  system  can  be  commended  to  and/or  report  its 
driving  mode.  At  a  minimum,  the  following  driving  modes  are  considered  applicable: 

Remote  Control  (RC)  Provides  the  ability  to  move/drive  the  platform  with  eyes  on  the 

robotic  system 

Teleoperation  (Teleop)  Provides  the  ability  to  move/drive  the  platform  through  a 

dedicated  sensor(s). 

Basic  Navigation  (BN)  Provides  the  ability  to  move/drive  the  platform  via  a  defined  set 

of  points  specified  by  an  external  source. 

Leader/Follower  (L/F)  Provides  the  ability  to  move/drive  the  platform  in  relation  to  an 

external  source  (e.g.,  vehicle  or  dismounted  soldier).  In  this 
mode  the  robotic  platform  may  be  designated  as  either  a  leader 
or  a  follower. 

Limitations  and  Constraints:  Some  of  the  driving  modes  (e.g.,  basic  navigation)  may 
require  an  autonomy  package  integrated  to  the  platform  vehicle  control  system.  This 
version  is  not  concerned  with  defining  those  internal  interfaces  at  this  time  or  further 
subsetting  capabilities  into  mobility  payload  packages.  It  is;  however,  likely  that  these 
interfaces  (and  potentially  additional  subsetting)  will  be  defined  in  subsequent  revisions. 
The  degree  to  which  mobility  modes  may  affect,  limit,  or  relate  to  the  platform  mode 
should  be  considered  in  the  detailed  definition  of  this  capability.  In  addition,  the 
successful  transition  into  some  driving  modes  may  be  dependent  upon  the  availability 
and  status  of  a  related  subsystem  (for  example,  selection  and  enabling  of  a  driving 
sensor  -  from  the  point  of  view  of  the  robotic  platform  -  may  be  required  prior  to 
successful  transition  to  and/or  execution  of  teleop  driving,  where  this  would  not  be  the 
case  for  other  driving  modes). 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality.  In  some  cases,  additional  JAUS  messages  may  need  to  be 
recommended. 

3. 1.3. 2  Gear 

Description:  Conceptually  specifies  the  manner  in  which  the  robotic  platform  can  be 
commanded  to  and  will  report  its  method  of  movement  (e.g.,  forward,  reverse,  pivot) 
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Limitations  and  Constraints:  The  manner  in  which  this  capability  is  implemented  will 
be  determined  by  the  WIPTs  as  systems  vary  with  respect  to  the  implementation  of  this 
capability.  The  term  conceptual  is  used  in  the  description  as  a  specific  drive  select 
function  may  not  be  required  (e.g.,  utilization  of  +/-  values  could  determine  direction  vs. 
a  separate  mode  variable).  The  main  requirement  is  to  consistently  map  the  required 
behavior.  This  capability  is  applicable  to  the  RC  and  Teleop  drive  modes. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.1. 3.3  Speed/Acceleration 

Description:  Specifies  the  manner  in  and  the  degree  to  which  the  robotic  platform  will 
move  and  report  its  movement  as  commanded/queried  by  an  external  source.  This  will 
also  allow  control  of  speed  and  acceleration,  as  defined  by  the  speed  and  acceleration 
limits. 

Limitations  and  Constraints:  It  is  envisioned  that  for  the  basic  platform  there  will  be 
one  method  defined  and  associated  with  this  capability.  The  capability  to  set  is 
applicable  to  the  RC  and  Teleop  drive  modes. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3. 1.3.4  Speed/Acceleration  Limits 

Description:  Specifies  the  limits  associated  with  the  movement  of  the  robotic  platform. 
These  are  intended  to  be  reported  only  and  not  set  by  an  external  source,  as  these 
limits  are  inherent  platform  constraints  and  not  user  defined  or  settable. 

Limitations  and  Constraints:  There  may  be  an  association  of  these  limits  in  relation  to 
the  commanded  speed  and  acceleration.  If  so,  the  WIPTs  will  need  to  define  those 
relationships.  This  capability  to  set  is  applicable  to  the  RC  and  Teleop  drive  modes. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3.1. 3.5  Steering 

Description:  Specifies  the  manner  in  and  the  degree  to  which  the  robotic  platform  will 
turn  and  report  its  turning  as  commanded  /  queried  by  an  external  source. 

Limitations  and  Constraints:  It  is  envisioned  that  for  the  basic  platform  there  will  be 
one  method  defined  and  associated  with  this  capability.  This  capability  is  applicable  to 
the  RC  and  Teleop  drive  modes. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 
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3. 1.3. 6  Brake 

Description:  Conceptually  specifies  the  manner  in  which  the  vehicle  will  slow  or 
decelerate.  This  capability  is  stated  to  be  conceptual  due  to  the  fact  that  braking  may 
be  defined  as  the  absence  of  acceleration  vs.  a  specific  independent  function  in 
accordance  with  the  system  design. 

Limitations  and  Constraints:  Regardless  of  the  presence  or  absence  of  a  physical 
brake(s),  this  capability  shall  be  implemented  consistently.  This  capability  is  applicable 
to  the  RC  and  Teleop  drive  modes. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3. 1.3.7  Drive  Sensor  Registration 

Description:  Provides  the  capability  to  identify  and  report  a  sensor  as  applicable  to 
driving.  Some  platforms  may  have  one  (or  none)  driving  sensor  however  other 
platforms  may  have  multiple  sensors  specifically  located  (e.g.,  front,  rear  side)  to  be 
associated  with  teleoperation  of  the  robotic  platform. 

Limitations  and  Constraints:  Conceptually  this  capability  provides  an  external  source 
with  information  related  to  the  availability  of  sensors  best  suited  to  remotely  operate  the 
platform.  It  may  be  the  case  that  a  robotic  platform  has  only  one  sensor  (associated 
with  multiple  tasks)  or  does  not  define  a  driving  sensor  and  would  need  to 
accommodate  this  capability  in  the  best  manner  possible.  This  capability  is  applicable 
to  all  driving  modes  with  the  exception  of  RC. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3.1 .3.8  Drive  Sensor  Selection 

Description:  Provides  the  capability  to  select  and  view  sensor  video  associated  with 
driving  the  robotic  platform. 

Limitations  and  Constraints:  From  the  point  of  view  of  the  robotic  platform  driving 
sensor(s)  can  be  selected  and  enabled/disabled  by  an  external  source  and  there  is  no 
intent  to  limit  the  ability  to  send  multiple  or  multiplexed  video  from  several  sources  for 
display.  In  addition,  the  selection  of  the  source  is  not  explicitly  intended  to  enable  video 
transmission;  however,  that  collective  capability  may  be  implemented  within  an  external 
control  system.  This  capability  is  applicable  to  all  driving  modes  with  the  exception  of 
RC. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3. 1.3. 9  Drive  Timeout 

Description:  Provides  a  capability  to  monitor  control  messages  from  an  external  source 
to  the  robotic  platform  at  a  determined  frequency  to  ensure  that  a  loss  of  commanded 
input  along  the  control  chain  does  not  result  in  unintended  consequences  or  safety 
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issues.  Conceptually,  this  is  a  watchdog  function  to  prevent  stale  data  in  the  control 
chain  from  commanding  the  system. 

Limitations  and  Constraints:  This  capability  is  addressed  within  the  robotic  platform 
(perhaps  at  multiple  levels  depending  upon  the  control  logic),  but  also  needs  to  be 
considered  external  to  the  platform  as  well  (for  example,  within  a  controller,  multiple 
processes  might  be  used  to  read  handle  data,  process  control  input,  and  command 
vehicle  movement).  This  capability  is  applicable  to  the  RC  and  Teleop  driving  modes. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.1 .3.1 0  Create  Waypoint/Waypoint  List 

Description:  Provides  a  capability  to  define  a  waypoint  and  an  associated  list  of 
waypoints  that  can  be  utilized  for  simple  navigation  of  the  robotic  platform  along  a  path. 

Limitations  and  Constraints:  This  capability  is  intended  to  provide  a  simple  navigation 
mechanism.  The  waypoint  is  intended  to  represent  a  geo-location  and  may  define 
some  simple  level  of  tolerance  with  respect  to  signifying  the  capture  of  the  waypoint 
itself  and  desired  speed  between  path  segments.  Actions  at  waypoints,  waypoint  time 
constraints  (e.g.,  arrival  and  departure),  plan  volatility,  plan  validation,  multi-plan 
definition/selection,  and  waypoint  corridors  are  deferred  to  subsequent  versions.  Plan 
volatility  and  the  ability  to  define  multiple  plans  are  not  explicitly  addressed,  but  if 
addressed  by  the  WIPTs  must  be  done  so  in  a  manner  that  keeps  the  functionality 
applicable  across  the  set  of  systems  that  provide  basic  waypoint  navigation.  This 
capability  is  applicable  to  the  BN  driving  mode. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.1 .3.1 1  Insert/Delete  Waypoint 

Description:  Provides  the  capability  to  insert  or  delete  a  waypoint  from  a  waypoint  plan. 

Limitations  and  Constraints:  It  is  presumed  that  waypoint  insertion  and  deletion  would 
only  occur  with  respect  to  a  non-executing  plan.  This  capability  is  applicable  to  the  BN 
driving  mode. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.1.3.12  Load  Waypoint  Plan 

Description:  Provides  the  capability  to  load  a  defined  waypoint  plan  for  processing 
(execution)  by  the  robotic  platform. 

Limitations  and  Constraints:  While  there  is  no  requirement  to  explicitly  validate 
waypoint  plans,  this  capability  may  take  simple  checks  into  account  prior  to  signifying 
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the  readiness  to  execute  a  specified  plan.  This  capability  is  applicable  to  the  BN  driving 
mode. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality.  Also,  for  VO,  the  utilization  of  JAUS  may  nullify  the  need  for  an  explicit 
“load”  function.  WIPTs  are  allowed  to  implement  this  and  other  waypoint  functions  in  a 
“conceptual”  manner.  However,  future  planning  requirements  may  require  more 
separation  between  creation  and  loading  with  respect  to  waypoint  (mobility)  plans,  as 
these  plans  may  be  more  integrated/related  to  other  capabilities  within  higher  level 
mission  plans  (e.g.  ISR). 

3.1 .3.1 3  Execute  Waypoint  Plan 

Description:  Provides  the  capability  to  initiate  execution  of  a  loaded  waypoint  plan. 
Once  the  plan  is  executing,  there  are  various  events  that  can  happen  that  may  affect 
the  plan  execution  state  (e.g.,  intervention  required).  These  conditions  need  to  be 
considered  in  the  definition  of  the  functionality. 

Limitations  and  Constraints:  State  machine  logic  associated  with  the  load,  execute, 
pause,  and  resume  process  will  need  to  be  defined  by  the  WIPT.  In  addition,  the 
relationship  of  the  plan  execution  state  to  the  driving  mode  state  will  also  need  to  be 
addressed/defined  by  the  WIPT  (e.g.,  selecting  the  teleop  driving  mode  while  the  plan  is 
currently  executing).  This  capability  is  applicable  to  the  BN  driving  mode. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.1.3.14  Waypoint  Plan  Status 

Description:  Provides  the  capability  to  report  the  status  of  the  plan  execution  state 
machine  to  an  external  source.  Plan  status  will  also  provide  an  indication  and  distance 
to  the  current  target  waypoint. 

Limitations  and  Constraints:  This  capability  will  be  largely  tied  to  the  waypoint  plan 
execution  state  machine  model.  This  capability  is  applicable  to  the  BN  driving  mode. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.1.3.15  Suspend/Resume  Waypoint  Plan 

Description:  Provides  the  capability  to  pause  and  re-initiate  execution  of  a  currently 
loaded/executing  waypoint  plan. 

Limitations  and  Constraints:  Similarly  to  plan  execution,  the  relationship  of  the  plan 
execution  state  and  the  driving  mode  state  will  need  to  be  addressed/defined  by  the 
WIPT.  In  addition,  the  ability  to  reload  or  re-execute  a  plan  while  in  a  paused  state  will 
also  need  to  be  considered.  This  capability  is  applicable  to  the  BN  driving  mode. 
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Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.1.3.16  Leader/Follower  Mode 

Description:  Provides  the  ability  to  specify  the  robotic  platform  leader/follower  mode 
within  a  leader/follower  configuration.  For  this  basic  capability,  the  robotic  platform  will 
simply  be  designated  as  a  “Leader”  or  a  “Follower.”  The  intent  of  the  leader  capability 
requirement  is  to  provide  a  simple  position  designation  to  a  set  of  external  followers. 

The  intent  of  the  follower  capability  is  to  monitor  a  simple  position  report  from  a 
designated  follower  and  follow  the  position  in  accordance  with  a  defined  set  of 
attributes. 

Limitations  and  Constraints:  Similarly  to  basic  navigation,  leader/follower  capability 
will  execute  in  accordance  with  a  set  of  defined  states/state  transitions.  The 
dependencies  of  these  states  along  with  the  platform  mode  and  other  executing  mobility 
state  machines  will  need  to  be  considered.  An  example  is  specifying  that  the  robot  is  to 
be  a  leader  and  then  providing  and  executing  a  waypoint  plan.  This  capability  is 
applicable  to  the  L/F  driving  mode. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended.  There  are 
multiple  ways  to  accomplish  this  task,  which  will  need  to  be  identified  and  evaluated. 

3.1.3.17  Formation  Attributes 

Description:  Provides  the  ability  to  specify  a  set  of  attributes  to  oversee  the  formation 
during  execution.  In  general,  these  attributes  will  be  most  applicable  when  the 
leader/follower  mode  is  set  to  follower.  Follower  attributes  include  min/max  following 
distance,  position/offset  with  respect  to  lead  vehicle,  lead  vehicle  designation,  and 
timeout  behaviors.  Leader  attributes  include  broadcast/multicast  group,  position  update 
frequency,  and  timeout  behaviors. 

Limitations  and  Constraints:  Specific  formation  algorithms  and  multi-vehicle 
formations  are  not  intended  to  be  explicitly  addressed  by  this  capability.  These 
formations  may  be  addressed  in  future  revisions  or  at  a  time  when  such  behaviors 
become  standardized  within  the  community.  This  capability  is  applicable  to  the  L/F 
driving  mode. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended.  There  are 
multiple  ways  to  accomplish  this  task,  which  will  need  to  be  identified  and  evaluated. 

3.1.3.18  Execute  Formation 

Description:  Provides  the  capability  to  initiate  execution  of  configured  leader/follower 
formation.  Once  the  formation  is  executing,  there  are  various  events  that  can  happen 
that  may  affect  the  plan  execution  state  (e.g.,  loss  of  communications).  These 
conditions  need  to  be  considered  in  the  definition  of  the  functionality. 
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Limitations  and  Constraints:  State  machine  logic  associated  with  the  leader/follower 
execution  will  need  to  be  defined  by  the  WIPT.  In  addition,  the  relationship  of  the 
leader/follower  execution  state  to  the  driving  mode  state  will  also  need  to  be 
addressed/defined  by  the  WIPT  (e.g.,  selecting  the  teleop  driving  mode  while  a 
formation  is  currently  executing).  This  capability  is  applicable  to  the  L/F  driving  mode. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3.1.3.19  Following  Status 

Description:  Provides  the  capability  to  report  the  status  of  the  leader/follower  execution 
state  to  an  external  source.  Although  this  will  be  defined  by  the  WIPTs,  this  may  include 
a  confirmation  that  the  follower  is  the  correct  range. 

Limitations  and  Constraints:  This  capability  will  be  largely  tied  to  the  leader/follower 
execution  state  machine  model.  This  capability  is  applicable  to  the  L/F  driving  mode. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3.1.3.20  Suspend/Resume  Waypoint  Leader/Follower 

Description:  Provides  the  capability  to  pause  and  re-initiate  execution  of  a  defined 
leader/follower  mode  of  operation. 

Limitations  and  Constraints:  Similarly  to  leader/follower  execution,  the  relationship  of 
the  leader/follower  execution  state  and  the  driving  mode  state  will  need  to  be 
addressed/defined  by  the  WIPT.  This  capability  is  applicable  to  the  L/F  driving  mode. 

Other  Guidance:  Current  JAUS  capabilities  are  intended  to  map  to/provide  this 
functionality. 

3.2  Payload 

The  payload  section  is  currently  divided  into  3  subsections.  The  sensor  section  is  used 
to  describe  devices  that  sense  conditions,  both  on  and  off  the  platform.  The  emitter 
section  is  used  to  describe  devices  that  emit  or  release  material  or  energy  into  the 
platform  surroundings.  And  finally,  the  actuator  section  described  devices  used  to 
physical  manipulate  portions  of  the  platform,  other  sensors,  or  the  surroundings.  In 
some  cases,  a  payload  may  not  be  clearly  placed  into  one  of  these  groupings.  When 
this  occurs,  the  primary  function  of  the  payload  will  be  considered,  and  will  be  identified 
by  the  RS  JPO.  (Example:  While  a  laser  range  finder  does  emit  electro-magnetic 
energy,  the  primary  function  is  to  sense  distance.) 
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3.2.1  Sensor 

3. 2. 1.1  Drive  Vision 

Description:  Drive  vision  describes  motion  imagery  necessary  to  drive  a  robotic 
platform  in  teleop  mode.  This  provides  the  capability  to  interface  drive  vision  payloads 
onto  robotic  systems. 

Limitations  and  Constraints:  This  should  include  on/off,  zoom,  video  image  format, 
any  necessary  metadata  required,  and  anything  that  the  WIPT  identifies  as  necessary. 
For  VO,  only  simple  video  is  required.  Later  versions  can  include  frame  rate 
adjustments,  image  resolution,  and  other  settings. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended.  Motion 
imagery  standards  should  be  utilized.  This  may  be  related  to  motion  imagery. 

3. 2. 1.2  Motion  Imagery 

Description:  Motion  imagery  describes  any  video  that  is  not  specifically  used  to  drive 
the  system,  although  it  could  be  used  to  do  so.  This  provides  the  capability  to  interface 
motion  imagery  payload  to  robotic  systems. 

Limitations  and  Constraints:  This  could  include,  on/off,  zoom,  focus,  gain,  video 
image  formats,  and  anything  that  the  WIPTs  deem  necessary.  For  VO  only  simple  2-D 
imagery  is  needed. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended.  This  may 
be  related  to  drive  sensors. 

3. 2. 1.3  Still  Imagery 

Description:  The  robot  may  need  to  take  still  imagery  at  times.  This  provides  the 
capability  to  interface  still  imagery  payload  to  robotic  systems. 

Limitations  and  Constraints:  This  feature  can  be  defined  by  the  WIPTs,  but  may 
include  capture  commands,  zoom,  and  image  format  among  other  parameters. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3.2.1. 4  CBRN 

Description:  Provides  the  capability  to  interface  Chemical,  Biological,  Radiology  and 
Nuclear  (CBRN)  detection  sensors  to  robotic  systems. 

Limitations  and  Constraints:  The  VO  plan  should  include  on/off,  sensitivity  levels, 
specificity  of  chemical,  false  alarm  control,  and  anything  the  WIPT  determines  is 
necessary.  This  capability  will  need  to  expand  in  the  future,  as  additional  requirements 
are  identified. 
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Other  Guidance:  Joint  Program  Executive  Office  for  Chemical  Biological  Defense 
(JPEO-CBD)  is  developing  a  standard  for  sensor  physical,  electrical  interfaces,  power 
requirements,  component  interconnections,  power  and  external  connectors  for  CBRN 
sensors.  Additional  JAUS  messages  may  need  to  be  recommended. 

3. 2. 1.5  Chemical  Explosive  Detection 

Description:  Provides  the  capability  to  interface  chemical  explosive  detection  sensor  to 
robotic  systems. 

Limitations  and  Constraints:  This  may  include  on/off,  sensitivity  levels,  specificity  of 
chemical,  false  alarm  control,  and  anything  else  the  WIPT  identifies  that  is  required. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3. 2. 1.6  Microphone 

Description:  Provides  the  capability  to  interface  microphone  sensors  to  robotic 
systems.  This  will  allow  the  operator  to  collect  audio  from  the  area  in  which  the  robot  is 
located. 

Limitations  and  Constraints:  The  VO  plan  should  include  on/off  capability  and  audio 
format.  The  VO  plan  is  not  intended  to  include  the  ability  to  perform  gunfire  detection,  or 
sonar-type  mapping. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3. 2. 1.7  Range  Finder 

Description:  Provides  the  capability  to  interface  electronic  range  finder  payloads  to 
robotic  systems.  Laser  range  finders  (LRF)  (aka  Light  Detection  and  Ranging  (LIDAR) 
or  Laser  Detection  and  Ranging  (LADAR)  sensors)  are  a  combination  emitter  and 
sensor  but  their  primary  function  is  to  “sense”  distance  to  objects.  Some  LRF  are  used 
in  target  acquisition  to  determine  distance  to  targets,  but  there  are  also  scanning  laser 
range  finders  that  are  used  in  robotics  to  develop  three  dimensional  map  of 
surroundings  for  autonomous  path  following  and  obstacle  detection.  Further,  this 
capability  can  also  be  deployed  in  detecting  Nuclear  Biological  and  Chemical  (NBC) 
particle  clouds. 

Limitations  and  Constraints.  This  should  include  on/off  capability,  type  of  range 
finder,  distance  to  target,  and  data  format.  For  VO,  LIDAR  units  are  not  included.  VO  will 
only  require  simple  range  finding. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3. 2. 1.8  Thermal 

Description:  Provides  the  capability  to  interface  thermal  sensors  to  robotic  systems. 
Thermal  sensors  are  used  for  the  sensing  of  heat  changes. 
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Limitations  and  Constraints:  VO  will  include  on/off  capability,  type  of  thermal  sensor 
and  data  format.  For  VO,  the  thermal  sensors  will  be  still  and  motion  imagery  based,  and 
not  individual  thermal  sensors  such  as  thermistors  or  thermocouples.  Based  on  the 
recommendations  of  the  WIPT,  this  feature  may  match  up  with  still  and  motion  imagery. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3.2.2  Emitter 

3. 2. 2.1  Lights 

Description:  Provides  the  capability  to  interface  lights  to  robotic  systems. 

Limitations  and  Constraints:  This  will  include  on/off  capability.  The  intent  is  to  control 
simple  lights  to  enhance  visual  capabilities.  The  intent  is  not  to  control  advanced  lighting 
systems,  dazzlers,  laser  designators,  and  the  like  for  VO.  WIPT  members  will  determine 
other  capabilities  that  need  to  be  added. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3. 2. 2. 2  Speaker 

Description:  Provides  the  capability  to  interface  speakers  to  robotic  systems. 

Limitations  and  Constraints:  VO  should  include  on/off  capability,  audio  format,  and 
volume,  as  well  as  other  controls  required  by  the  WIPT.  VO  is  not  intended  to  provide 
acoustic  weapon  capabilities,  or  other  advanced  capabilities.  The  audio  format  and 
frequency  range  may  need  to  be  determined. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 

3.2.3  Actuator 

Actuators  can  be  considered  very  similar  in  that  they  are  a  collection  of  various 
components  with  various  degrees  of  freedom.  An  actuator  could  be  as  simple  as 
controlling  translations  and  rotations.  However,  in  some  cases,  there  may  be  important 
features  the  user  or  robot  may  need  to  be  aware  of.  As  a  result,  specific  actuators  are 
described  and  included. 

3.2.3.1  Actuators 

Description:  Provides  the  capability  to  interface  actuators  to  robotic  systems. 

Limitations  and  Constraints:  The  VO  profile  should  include  the  type  of  actuator  (linear 
or  rotary),  on/off,  position,  speed,  and  other  parameters  required  by  the  WIPT.  As  there 
are  many  different  possible  embodiments  of  an  actuator,  only  a  simple  set  should  be 
considered. 

Other  Guidance:  Additional  JAUS  messages  may  need  to  be  recommended. 
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3. 2. 3. 2  Basic  Arm 

Description:  Provides  the  capability  to  interface  a  basic  arm  manipulator  on  robotic 
systems.  An  arm  could  include  a  payload,  which  is  positioned  by  the  arm. 

Limitations  and  Constraints:  The  VO  profile  should  include  degrees  of  movement, 
type  of  joint  movement,  on/off,  position,  speed,  and  other  features  recommended  by  the 
WIPTs. 

Other  Guidance:  ISO  8373  should  be  considered.  Additional  JAUS  messages  may 
need  to  be  recommended. 

3.2.3.3  Telescoping  (Mast) 

Description:  Provides  the  capability  to  interface  telescoping  mast  to  robotic  systems. 
The  mast  would  commonly  include  a  payload  that  is  raised/lowered  or 
extended/retracted . 

Limitations  and  Constraints:  VO  should  include  position  information,  on/off,  speed,  as 
well  as  any  other  requirements  as  defined  by  the  WIPT  members. 

Other  Guidance:  ISO  8373  should  be  considered.  Additional  JAUS  messages  may 
need  to  be  recommended. 

3. 2. 3.4  Pan/Tilt 

Description:  Provides  the  capability  to  interface  pan/tilt  payload  to  robotic  systems.  The 
pan/tilt  mechanism  can  be  used  to  change  the  direction  of  another  payload.  The  classic 
example  is  a  camera  that  can  look  left/right/up/down  by  moving  the  pan  and  tilt  feature. 

Limitations  and  Constraints:  VO  should  include  position/rotation  information,  on/off, 
speed,  as  well  as  other  features  required  by  the  WIPTs. 

Other  Guidance:  ISO  8373  should  be  considered.  Additional  JAUS  messages  may 
need  to  be  recommended. 


3. 2. 3.5  End  Effectors 

Description:  Provides  the  capability  to  interface  end  effectors  payload  to  robotic 
systems.  The  end  effectors  are  the  end-of-arm  tooling  on  a  robot.  As  other  payloads 
can  be  attached  to  the  end  of  an  arm,  such  as  a  sensor  or  emitter,  the  end  effector 
payload  is  defined  as  an  actuator  based  system,  like  a  gripper  or  cutter. 

Limitations  and  Constraints:  VO  should  include  position/rotation  information,  on/off, 
speed,  as  well  as  other  features  required  by  the  WIPTs. 

Other  Guidance:  ISO  8373  should  be  considered.  Additional  JAUS  messages  may 
need  to  be  recommended. 
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3.3  Communications 

The  communication  IOP  capabilities  are  focused  on  the  interoperability  of  the 
communications  system  as  interfaced  to  the  robotic  platform  and  to  the  controller 
system.  For  VO,  the  interface  between  radios  (e.g.,  protocols,  waveforms)  as  well  as 
the  interoperability  of  heterogeneous  radio  systems  are  not  specifically  addressed.  The 
main  intent  is  to  focus  the  communications  profile  to  support  the  set  of  currently  fielded 
systems  (platforms  and  controllers)  and  to  consider  the  radio  as  a  black  box  plug-in  to 
both  the  robotic  platform  and  the  controller  systems.  As  the  Army  community  defines 
requirements  for  large  scale  network  integration  of  robotic  platforms  and  controllers,  the 
communications  profile  capabilities  will  evolve.  The  communications  WIPT  may 
consider  the  establishment  of  working  groups  in  this  area  as  well  as  in  areas  dealing 
with  mesh  technologies,  encryption,  quality  of  service,  etc.,  to  contemplate  paths 
forward  as  well  as  standardization  and  interoperability  approaches  related  to  these 
topics  in  preparation  for  these  requirements. 

3. 3. 1.1  Radio  Link 

Description:  Provides  the  ability  to  establish  a  point  to  point  communications  link 
between  one  controller  and  one  robotic  platform  (closed  network). 

Limitations  and  Constraints:  This  capability  shall  take  into  consideration  the  setting  of 
radio  configuration  values  commensurate  with  currently  fielded  systems  (e.g.,  frequency 
channel). 

Other  Guidance:  It  is  desirable  for  the  identified  radio  link  parameters/configuration 
settings  to  be  settable  from  the  controller  system. 

3. 3. 1.2  Radio  Subsystem  Interface 

Description:  Provides  for  interoperability  with  respect  to  the  radio  subsystem  interface 
to  the  robotic  platform  and  the  radio  subsystem  interface  to  the  controller.  This  interface 
shall  consider  the  manner  in  which  the  radio  is  interfaced  with  respect  to  data 
bus/network  and  data  packets  to  include  both  control  data/status  as  well  as  video. 

Limitations  and  Constraints:  The  intent  of  this  capability  is  to  accommodate  currently 
fielded  systems  with  respect  to  the  receipt  and  transmission  of  data  and  video  to/from 
the  robotic  system  from  a  controller.  This  capability  will  need  to  consider  software  and 
hardware  related  to  the  networking  and  packetization  of  this  data  (e.g.,  Ethernet,  IP). 

Other  Guidance:  N/A 

3. 3. 1.3  Radio  Frequency  Interference  (RFI)  Mitigation 

Description:  Provides  the  ability  to  enable  the  operation  of  multiple  UGV  systems 
simultaneously  in  the  same  area  with  minimal  performance  degradation.  This  includes 
the  identification  (to  include  control  and  status  techniques)  of  parameters/configuration 
settings  that  can  be  queried,  accessed,  and  set  to  enable  maximized  performance  of 
UGVs  operating  in  the  same  vicinity  (examples  of  parameters  may  include  frequency 
settings,  transmit  power,  etc). 
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Limitations  and  Constraints:  The  intent  of  this  capability  is  to  maximize  the  inter¬ 
operation  of  multiple  one  to  one  controller/robot  systems  within  the  same  operational 
area.  This  feature  is  not  intended  to  be  an  automatic  frequency  adjustment. 

Other  Guidance:  It  is  desirable  for  the  identified  parameters/configuration  settings  to  be 
settable  from  the  controller  system. 

3.3.1. 4  Radio  Status  (Health) 

Description:  Provides  the  ability  to  query/report  the  radio  status  to  the  controller  or 
robotic  platform. 

Limitations  and  Constraints:  This  capability  shall  take  into  consideration  the 
availability  of  link/health  data  currently  available  in  fielded  systems  with  the  minimum 
goal  of  establishing  the  health  of  the  radio  and  the  network/link  status.  Other  potential 
attributes  include:  SNR,  Center  Frequency,  Channel  Frequency  Response,  Latency, 
Point  of  Modulation  Bandwidth,  Packet  Error  Rate  (%),  Data  Rate  (Mbps),  Modulation 
Scheme,  RF  Transmit  Power  (dBm),  Received  Signal  Power  (dBm),  Error  Vector 
Magnitude  (EVM),  Mode  of  Operation  (Point-to-Point  or  Multipoint). 

3. 3. 1.5  Wireless  Security 

Description:  Provides  the  ability  to  establish  secure,  encrypted  wireless 
communications  links. 

Limitations  and  Constraints:  For  the  purposes  of  VO,  this  shall  be  limited  to  querying 
for  the  available  encryption  schema  on  a  given  radio,  and  turning  encryption  schema  on 
or  off.  Future  versions  of  the  IOP  are  anticipated  to  expand  the  wireless  security 
capabilities. 

Other  Guidance:  N/A 

3.4  Control 

The  control  IOP  capabilities  are  focused  on  interoperability  as  it  relates  to  a  control 
device,  specifically  in  the  areas  of  commonality,  operator  interfacing,  and  external 
system  interfacing  to  exchange  information  to/from  the  robotic  platform  (e.g.,  maps, 
sensor/image  data,  Command  and  Control  (C2)  and  situational  awareness  data). 
Commonality  in  this  sense  does  not  necessarily  mean  only  the  standardization  of  the 
user  interface,  but  instead  is  focused  towards  usability,  common  presentation  of 
information,  and  common  interaction  techniques  across  a  variety  of  input  and  output 
devices. 

Major  requirements  sections  within  the  Control  IOP  include  Software,  Human  Computer 
Interface  (HCI),  C2,  and  Mission  Planning.  The  following  sections  address  the 
requirements  focus  for  these  areas  with  respect  to  VO  capabilities. 
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3.4.1  Software 

These  requirements  are  related  to  standardization  of  operating  system,  operating 
system  isolation  and  graphics  software  to  support  application  interoperability.  In 
addition,  the  introduction  of  vendor  plug-in  software  and  safety  critical  applications 
would  require  the  need  to  define  interoperability  requirements  in  this  area.  For  VO, 
these  requirements  will  not  be  specifically  addressed,  however  working  groups  could  be 
established  to  discuss  needs  and  future  standardization  in  these  areas.  It  is  also  likely 
that  the  Army’s  Common  Operating  Environment  (COE)  initiative  will  explicitly 
define/mandate  standards  and  application  software  related  to  these  requirements  and 
as  such,  will  defer  detailed  analysis  in  this  area  until  VI  or  later. 

3.4.2  HCI 

These  requirements  are  related  to  the  standardization  of  the  human  computer  interface 
employed  within  the  controller  systems.  It  is  understood  that  controllers  will  be  adapted 
to  various  input/output  device  configurations  and  as  such,  these  requirements  will  not 
be  focused  on  a  common  interface  but  will  be  more  focused  on  common  techniques  to 
be  adapted  across  interfaces  applying  to  both  the  output  of  information  to  a  soldier  and 
the  input  controls  required  to  implement  the  soldier’s  intent  to  a  robotic  platform. 

3.4.2.1  Battery  Status 

Description:  Provides  the  status  of  the  battery(ies)  or  other  power  source  utilized  to 
power  the  controller.  The  intent  is  to  provide  a  current  charge  level  of  the  battery  or 
status  of  the  power  system. 

Limitations  and  Constraints:  The  intent  is  to  provide  just  the  charge  level  of  the 
battery,  allowing  the  user  to  make  informed  decisions  about  mission  capability.  In 
subsequent  versions,  additional  information  may  be  added  (e.g.,  battery  chemistry, 
loads,  temperature,  critical  levels).  The  WIPTs  may  add  additional  information  as 
deemed  important  for  basic  functionality,  but  advanced  functions  should  not  be  pursued 
at  this  time. 

Other  Guidance:  N/A 

3.4.2. 2  Radio  Setup  and  Communications  Link  Monitoring 

Description:  Provides  the  ability  to  select  a  radio  configuration  and  establish  and 
monitor  an  RF  connection  to  a  robotic  platform. 

Limitations  and  Constraints:  This  capability  is  meant  to  map  closely  to  capabilities 
currently  provided  in  fielded  systems  as  well  as  capabilities  developed/identified  within 
the  communications  portion  of  the  IOP. 

Other  Guidance:  N/A 
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3.4.2. 3  Robotic  Asset  Selection,  Login,  and  Controls 

Description:  Provides  the  ability  to  select  and  login  to  a  robotic  asset.  This  includes 
the  ability  to  command  startup,  shutdown,  and  operational  usage  of  the  robotic  asset 
and  to  the  degree  specified  within  other  areas  of  the  profile  determine  available 
capabilities/configuration  of  the  robotic  platform. 

Limitations  and  Constraints:  This  capability  should  be  limited  by  the  degree  to  which 
other  capabilities  are  defined  within  the  overarching  and  payload  profiles  with  respect  to 
discovery  and  configuration  of  the  robotic  platform  and  could  range  from  a  simple 
selection/visualization  of  the  asset  under  control  to  a  broader  capability  that  presents 
the  robotic  configuration  to  the  controller. 

Other  Guidance:  N/A 

3. 4. 2. 4  Common  Icons  and  Graphics 

Description:  Provides  the  ability  to  define  common  graphics  and  icons  to  be  utilized  in 
the  presentation  of  robotic  information  and  status  to  the  operator. 

Limitations  and  Constraints:  In  general,  this  capability  is  aimed  at  determining 
graphics  and  icon  commonality  related  to  the  capabilities  available  in  currently  fielded 
systems  and  capabilities  defined/implemented  for  VO.  Icons  and  graphics  could  include 
things  such  as  robot  position/articulation,  arm  articulation,  speed,  communications 
link/link  status,  battery  status,  etc. 

Other  Guidance:  N/A 

3.4.2.5  Basic  Status 

Description:  Provides  the  ability  to  define  basic  status  information  along  with  guidelines 
for  presentation  to  be  displayed/communicated  to  the  operator.  This  could  be  status 
related  to  current  robotic  platform  states/modes,  date/time  group,  robotic  asset 
position/location,  battery  status  (platform  and  OCU),  fuel,  RPM,  temperature,  etc. 

Limitations  and  Constraints:  This  capability  will  be  limited  by  the  set  of  information 
defined  within  other  portions  of  the  profile  for  VO. 

Other  Guidance:  The  guidelines  are  meant  to  provide  some  basic  rules/rationale  for 
when/how  the  information  should  be  displayed.  For  example,  vehicle  attitude  data  may 
be  specified  to  be  always  available  during  teleoperation  and  selectable  at  other  times 
(e.g.,  when  observing  or  when  in  autonomous  mode). 

3.4.2. 6  Warnings  Cautions  and  Alerts 

Description:  Provides  the  ability  to  receive  and  display  warnings,  cautions,  and  alerts 
(WCAs)  to  the  operator  in  a  predictable  and  prioritized  manner.  WCAs  may  be 
generated  by  the  robotic  platform  or  internally  generated  on  the  controller  system. 
Examples  could  include  low  battery,  over  temperature  conditions,  component  failure,  or 
tip  hazard. 
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Limitations  and  Constraints:  This  capability  is  intended  to  provide  some  common 
means  to  display  and  dispatch  WCAs  and  could  include  the  definition  of  one  or  more 
display  mechanisms  that  could  include  operator  cueing  (e.g.,  audible  or  graphic).  The 
resultant  implementation  could  be  specific  (e.g.,  the  definition  of  a  widget  to  be 
incorporated  into  a  WMI  design)  or  more  abstract  (e.g.,  a  structure  and  rule  set  for 
handling  and  presenting  WCAs  to  the  operator. 

Other  Guidance:  N/A 

3. 4. 2. 7  State  and  Mode  Selection 

Description:  Provides  the  ability  to  select  and  indicate  various  states  and  modes  of 
operation  for  the  robotic  platform  in  accordance  with  its  capabilities.  This  could  include 
mobility  modes  (teleoperation,  autonomous)  as  well  as  selection  of  manipulator  control 
modes. 

Limitations  and  Constraints:  This  capability  will  be  limited  by  capabilities  specified 
within  other  parts  of  the  profile  and  is  intended  to  map  to  current  capabilities 
implemented  within  fielded  systems  as  well  as  the  overarching  and  payload  capabilities 
specified  within  VO. 

Other  Guidance:  N/A 

3.4.2.8  Input  Device  Mapping  (Mobility  and  Manipulator  Control) 

Description:  Provides  the  ability  to  define  a  set  of  common  controls/control  mappings 
for  mobility  (teleoperation)  and  manipulator  (arm)  control. 

Limitations  and  Constraints:  This  capability  is  intended  to  provide  common  mappings 
to  various  input  devices  (e.g.,  game  controllers,  joystick,  etc)  to  control  mobility  and 
manipulator  payloads  for  the  robotic  platform.  This  is  intended  to  be  a  rule  set  to  map  to 
devices  currently  integrated  with  fielded  controllers.  At  this  point  in  time,  this  is  not 
intended  to  address  advanced  control  capabilities  such  as  speech,  gesture  recognition, 
etc. 

Other  Guidance:  N/A 

3.4.2. 9  Video  Window  (Viewing  and  Controls) 

Description:  Provides  the  ability  to  select  and  view  video  from  a  robotic  platform  to 
include  the  selection  of  the  video  source  and  the  provision/implementation  of  video 
controls  in  accordance  with  the  sensor  (e.g.,  FOV,  focus,  zoom,  TV/IR,  etc)... 

Limitations  and  Constraints:  This  capability  is  intended  to  map  to  video  capabilities  of 
currently  fielded  systems  and  will  be  limited  by  the  capabilities  defined  within  the  VO 
payload  profile. 

Other  Guidance:  N/A 
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3.4.2.10  Image/Video  Archive  and  Browsing 

Description:  Provides  the  ability  to  store  and  retrieve  images  and  video  taken  from  a 
robotic  sensor. 

Limitations  and  Constraints:  In  general,  this  capability  provides  a  standardized 
mechanism  to  archive  and  retrieve  image  and  video  data  captured  from  a  sensor  on  a 
robotic  platform.  Metadata  requirements  such  as  the  platform,  time  of  day,  location, 
orientation,  sensor  attributes,  etc  may  be  required  to  be  stored  with  the  imagery  and 
should  be  taken  into  consideration  when  defining  this  capability, 

Other  Guidance:  N/A 

3.4.3  Command  and  Control  (C2) 

These  requirements  are  related  to  the  interfacing  of  a  controller  to  battlefield  command 
and  control  systems  to  receive  and  transmit  command  and  control  and  situational 
awareness  data.  For  VO,  these  requirements  will  not  be  specifically  addressed, 
however  working  groups  could  be  established  to  discuss  needs  and  future 
standardization  in  these  areas.  It  is  likely  that  ongoing  work  in  PEO-I  and  the  Army’s 
Common  Controller  program  could  lead  to  the  establishment  of  future  requirements  in 
this  area. 

3.4.4  Mission  Planning 

These  requirements  are  related  to  interoperability  between  controllers  and  mission 
planning  systems  to  exchange  unmanned  asset  plans  which  can  be  sent  to/received 
from  robotic  platforms.  VO  defines  requirements  for  simple  autonomy  (mobility/waypoint 
plans)  related  to  single  robotic  assets. 

3.4.4.1  Mission  Plan  Metadata  and  Graphics 

Description:  Provides  the  ability  to  specify  a  set  of  simple  mission  plan  features  (e.g., 
waypoints,  corridors)  and  plan  parameters  (e.g.,  speed)  in  support  of  the  waypoint 
planning  and  leader/follower  capabilities  specified  for  VO. 

Limitations  and  Constraints:  For  VO,  this  capability  is  limited  to  plan  structures  and 
plan  graphics  specified  for  internal  use.  This  capability  should  consider  current  doctrine 
and  symbology  related  to  mission  planning,  and  while  this  capability  should  be  specified 
to  map  to  external  planner  systems,  there  is  not  a  direct  intent  to  adopt  or  explicitly 
define  an  interface  to  a  current  planning  software  application  or  product.  In  addition,  it 
is  likely  that  metadata  formats/structures  defined  in  this  version  will  be 
adapted/expanded  for  future  versions. 

Other  Guidance:  Mil-Std  2525  should  be  utilized  for  the  specification  of  common 
symbology. 
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